MENTAL, un Lenguaje Formal de Especificacion

MENTAL, UN LENGUAJE
FORMAL DE
ESPECIFICACIÓN

“En el campo de la informática, el momento de la verdad es un programa al ejecutarse; todo lo demás es profecía” (Herbert Simon)

Concepto de especificación

La especificación de un sistema informática se ha asociado tradicionalmente a la tarea inicial que hay que realizar en todo proyecto software: la descripción de las características y funcionalidades del sistema a construir, así como las restricciones y limitaciones impuestas.

Lo que distingue a la especificación es el “qué”: lo que tiene que hacer el sistema. Las tareas subsiguientes de un proyecto (diseño, codificación y pruebas) se orientan al “cómo”, a la manera concreta de llevar a cabo las tareas descritas en la especificación.

Pero realmente la frontera entre el “qué” y el “cómo” es difusa, pues en el diseño, e incluso en la propia programación, hay también elementos especificadores, aunque a un mayor nivel de detalle. Lo que ocurre es que realmente todo es especificación y que el “qué” se convierte en “cómo” al aumentar el grado de detalle.

Los propios lenguajes de programación tienen aspectos especificadores. En efecto, la mayoría de ellos no establecen de forma clara la distinción entre el "qué" y el "cómo". Ambos aspectos se encuentran mezclados en la definición de cada lenguaje.

Es por ello que a veces se hace la distinción entre:

Especificación funcional.
Corresponde a la descripción de alto nivel de las funciones que debe realizar el sistema.
Especificación orgánica o de diseño.
Es una especificación más de detalle, una tarea puente entre la especificación funcional y la codificación.

Propiedades de la especificación

En general, las especificaciones de un sistema deben tener las propiedades siguientes [Ince, 1988]:

Precisión.
Muchos sistemas se especifican habitualmente mediante lenguaje natural, de forma imprecisa y a menudo ambigua. De aquí el interés en una notación formal que evite la ambigüedad.
Libre de directivas de diseño e implementación.
Una especificación “pura” debe de estar libre de este tipo de referencias, que de existir restringirían el espacio de soluciones y la creatividad. Se dice que una especificación es abstracta si se especifica el comportamiento de un sistema sin considerar su implementación.
Libre de detalle innecesario.
La especificación debe poder expresar la esencia de las funcionalidades del sistema, sin que obligue a considerar detalles, que serán expresados en una fase posterior.
Comprensible.
La especificación debe ser clara e inteligible para poder obtener la aceptación por parte del cliente.
Particionado.
La especificación debe separarse en módulos que puedan examinarse con mínimas o nulas referencias a otros módulos. Se puede hablar de “especificación modular”.

Lenguajes de programación vs. Lenguajes de especificación

Semántica.
Los lenguajes de especificación son de alto contenido semántico, de alto nivel de abstracción (para poder expresar el “qué”) lo general, pero su tendencia es hacia poder expresar también el “cómo”, el detalle.

En cambio, los lenguajes de programación tienen una semántica limitada e implementan abstracciones de bajo nivel. Pero la historia de los lenguajes de programación revela una evolución continua hacia mayores niveles de abstracción. Lo que hace unos años sería una especificación de alto nivel hoy se considera una forma natural de describir un proceso con un lenguaje de programación.
Nivel de detalle.
Los lenguajes de especificación se han ubicado generalmente en un nivel poco concreto y poco detallado, que puede conducir a diferentes interpretaciones o implementaciones. Actualmente hay una tendencia hacia la posibilidad de poder definir un mayor nivel de detalle en la especificación.

En cambio, los lenguajes de programación han tenido siempre la virtud de la concreción y no de la ambigüedad, pues realizan una tarea concreta. El nivel de detalle es alto.
Legibilidad.
La legibilidad de un lenguaje de especificación es total. En cambio, en los lenguajes de programación la legibilidad es pequeña, pues a veces es difícil deducir cual es el objetivo y oculto tras el código y, por consiguiente, pueden existir diferentes interpretaciones de un determinado código fuente.

La tabla siguiente resume estas y otras características. La flecha indica la tendencia (creciente o decreciente).

Característica	Lenguaje de especificación	Lenguaje de programación
Semántica	Alta	Baja↑
Nivel de detalle	Bajo↑	Alto
Legibilidad	Alta	Baja↑
Flexibilidad	Alta	Baja↑
Portabilidad	Siempre	No siempre
Desarrollo de prototipos	Si	No
Mantenimiento	Fácil	Difícil

Lenguajes de programación y de especificación tienden a converger, a unificarse, de tal forma que un sólo lenguaje puede servir para especificar un sistema o aplicación con el grado de detalle que se desee y que además sea ejecutable.

Lenguajes Formales de Especificación
La especificación de un sistema o aplicación se ha realizado de manera más o menos informal, pero siempre con el objetivo de organizar las ideas. Raras veces se ha utilizado una notación formal. Pero actualmente hay una línea de investigación orientada al uso de lenguajes formales de especificación, lo que implica la definición de una sintaxis y una semántica precisas.

Las especificaciones formales se han enfocado desde los puntos de vista:

Operacional o imperativo.
Se suministra un método constructivo.
Descriptivo.
Se suministra una lista de propiedades deseadas. Entre las formas descriptivas se encuentran las especificaciones algebraicas, las denotacionales y las axiomáticas.
Mixto.
Combina los dos aspectos anteriores.

Las representaciones de la especificación pueden clasificar en dos categorías: las de tipo gráfico y las de tipo textual. Entre las representaciones gráficas se encuentran: los diagramas Warnier-Orr, los diagramas de flujo de datos, los diagramas de transición de estados, etc. Hay representaciones que son híbridas (gráficas y textuales a la vez), como los diagramas HIPO, en el que se puede describir el proceso también de forma textual.

Los lenguajes formales de especificación utilizados han sido los siguientes:

Lenguaje natural

Es el más utilizado, pero tiene el problema de que es ambiguo. Para lograr una cierta precisión habría que usar las mismas palabras y la misma fraseología para describir los conceptos. Además existen dos problemas adicionales: 1) se dan por supuesto ciertos conocimientos en el lector (que no son precisos) y 2) las diferentes interpretaciones de las mismas palabras según las distintas culturas.

Pseudocódigo

Es una forma de especificar los procesos mediante el lenguaje natural pero haciendo uso, más o menos formalmente, de las estructuras básicas de la programación estructurada.

Con el pseudocódigo se posponen detalles de proceso, se mejora la comprensión del programa, pero:

Adolece también de cierta ambigüedad, pues no hay un lenguaje estándar definido.
Como su nombre indica, sólo se concentra en aspectos operacionales. No permite describir la información pasiva (datos). Habría que inventar en paralelo lo que podríamos llamar "pseudodatos".

Lenguajes de programación

Los lenguajes de programación suelen ser precisos, con lo que se cumple un importante requerimiento. Pero hay que distinguir entre:

Lenguajes de tercera generación (3GL).
Son básicamente de tipo operativo, por lo que la especificación había que darla principalmente en términos de un algoritmo (es decir, apoyarse en el "cómo"). Además el lenguaje de programación obliga a trabajar con información de detalle, con lo que se incumple un requerimiento de lo que debe ser una especificación.
Lenguajes de cuarta generación (4GL).
Estos lenguajes están cambiando la idea del término "lenguaje de programación", pues entre sus características están su forma próxima al lenguaje natural y ser de alguna forma descriptivos a la vez que imperativos. El problema es que estos lenguajes no son suficientemente genéricos, pues están orientados fundamentalmente a acceso a bases de datos.
Lenguajes de muy alto nivel.
HOPE, ML, MIRANDA y OBJ por ejemplo, sí podrían usarse como lenguajes de especificación, pero el problema reside en la distancia existente entre los conceptos utilizados por el lenguaje y los que habitualmente se utiliza en la especificación.

Abstracción de datos

Desde 1977, fecha en la que se acuñó el nombre, la abstracción de datos es un concepto que se ha convertido en una revolución de la programación por el avance que ha supuesto en la evolución hacia la especificación.

La idea principal de la abstracción de datos es la siguiente:

No existe un acceso directo a los datos de un objeto. El acceso es siempre indirecto, a través de un conjunto predefinido de procedimientos. Es decir, el propósito es permitir el uso de los datos sin conocer los detalles de implementación, es decir, ni la forma de almacenamiento de los datos ni los algoritmos específicos utilizados para su acceso o manipulación.

Respecto a los tipos de datos:

Los tipos de datos de los lenguajes tradicionales se basan en la definición de un conjunto de valores admisibles.
En los tipos abstractos de datos (TAD), el tipo está asociado a un conjunto de operaciones admisibles. Los TAD constituyen un concepto central en la programación orientada a objetos.

Las ventajas de la abstracción de datos para la especificación son:

Permite separar la especificación de la implementación.
En la especificación se definen las operaciones permitidas sobre los datos, es decir, el “qué”. En la implementación se indica la forma concreta de acceso a los datos, es decir, el “cómo”.
Unifica datos y procedimientos.
En los lenguajes tradicionales existe una clara distinción entre datos (la información a manipular, los elementos pasivos) y procedimientos (los agentes activos, los que llevan a cabo la manipulación de los datos). Con la abstracción de datos, esa distinción se diluye, pues los datos sólo se “ven” como operaciones.
Como toda abstracción, sirve para reducir la complejidad.
Fomenta la generalización al especificar las mismas operaciones sobre diversos conjuntos de datos que poseen propiedades comunes.
Clarifica la programación.
Aumenta la productividad de los desarrollos.
Permite implantar una disciplina para proteger los datos.

Y las desventajas son:

Hay dicotomía especificación-programación.
Es necesario desarrollar los correspondientes procedimientos implementadores asociados a las operaciones que se definen sobre los datos.
La abstracción de datos es solo un aspecto de la especificación.
No existe un lenguaje formal asociado.
La abstracción de datos es solo una técnica para acceder de forma indirecta a los datos.
La abstracción de datos no es genérica.
En la abstracción de datos, el programador puede decidir libremente las operaciones a realizar. La abstracción de datos genérica consistiría en determinar un conjunto predefinido de operaciones, siempre el mismo, que podrían usarse para todo tipo de datos.

Una aproximación a la abstracción de datos genérica es el modelo propuesto por Mills y Linger [1986]. En este modelo existen sólo tres estructuras básicas de datos: conjuntos, pilas y colas y una serie predefinida de operaciones para cada uno de estos tipos de datos. Mediante estas tres estructuras se elimina la necesidad de usar matrices y punteros. Se establece así un cierto paralelismo con la programación estructurada, que utiliza sólo tres estructuras de control: secuencia, selección e iteración.

Automatización de la especificación

Hay una tendencia creciente hacia la automatización de una especificación.

El ciclo de vida clásico está siendo alterado por nuevos enfoques que tratan de automatizar una cierta especificación original, manteniendo la semántica. Esta tendencia se hace más evidente por la crisis del modelo en cascada para el desarrollo del software.

El modelo de desarrollo en cascada es de tipo secuencial, en donde cada fase se realiza tras la anterior: especificación, análisis, diseño, codificación y pruebas. Adolece de graves inconvenientes que dificultan la automatización completa del ciclo de vida [Balzer, 1983] [Wegner, 1984]:

Discontinuidad en el proceso de desarrollo.
En las etapas iniciales del ciclo de vida, lo que se especifica es una abstracción más o menos informal de lo que se desea realizar. Esta abstracción se refina progresivamente hasta que se transforma en un cierto punto en código fuente. Este código fuente se puede considerar una especificación operacional, que indica cómo debe llevarse a cabo. Hay por lo tanto una discontinuidad en el proceso, que ocasiona que no se pueda verificar si el código fuente resultante se ajusta o no a la especificación inicial.
Mantenimiento a bajo nivel.
El mantenimiento hay que realizarlo a bajo nivel, en el código fuente, es decir, en la implementación. Esto constituye un problema, pues se rompe facilmente la relación entre la especificación y el código fuente, lo que puede conducir a errores.

Sistemas de Automatización de la Especificación
Generadores de programas

Ofrecen al usuario la posibilidad de desarrollar programas sin conocer prácticamente nada sobre lenguajes. Son los productos CASE (Computer Aided Software Engineering), muchos de los cuales tienen la posibilidad de generar código fuente. Estas herramientas tuvieron su auge a principios de los años 1990s y estaban orientadas a ordenadores centrales (mainframes). Con la irrupción de los ordenadores personales estos productos han dejado de utilizarse.

Metaprogramación

La metaprogramación (un concepto reflexivo) es “programar programas”, es decir, el desarrollo de programas que generan programas. Los pasos son:

Se escribe la aplicación A en un determinado lenguaje.
Un programa conversor o traductor C genera el programa B.
Se ejecuta el programa B.

Las ventajas de la metaprogramación son:

La tarea de programación clásica queda reducida exclusivamente al desarrollo de generadores de código.
Genera programas homogéneos, en el sentido de que son el resultado del mismo proceso de traducción.
Los cambios en la implementación están controlados al realizarse sólo en un sitio (el generador de código).
Es una manera eficiente de producir software, pues el esfuerzo de desarrollar un generador de código es mucho menor que el de desarrollar el sistema de forma tradicional en su totalidad.

Y las desventajas son:

Hay muchos lenguajes implicados: los lenguajes de los programas A, B y C.
La metaprogramación depende de tres factores:
1. El modelo computacional.
2. El lenguaje formal de especificación.
3. El programa generador de código.
Cada modelo computacional necesita, en general, un lenguaje de especificación diferente. Y para cada uno de estos lenguajes es necesario desarrollar su correspondiente generador de código.

Programación transformacional

Puesto que existen dificultades para lograr a la vez los objetivos de claridad y eficiencia, la programación transformacional separa estos dos aspectos y los aborda como tareas independientes.

Sus pioneros fueron Burstall y Durlington, en 1977. Estos autores sugieren que el programador debe diseñar y escribir un programa con el único propósito de que sea inteligible y claro, sin considerar en ningún momento la eficiencia. A continuación el programa es sucesivamente transformado en versiones más y más eficientes del original, sin alterar su significado.

El programa construido inicialmente es una especificación que describe el problema a resolver, de la manera más clara posible. Además, su validez se puede demostrar antes de que se apliquen las transformaciones, siendo el resultado final igualmente válido.

Este modelo ha estado disponible sólo para pequeños productos y en dominios limitados: hojas de cálculo, aplicaciones de gestión con 4GLs, etc.

La especificación operacional se transforma sucesivamente, mediante un proceso mecanizado, hasta que se obtiene un código fuente optimizado. En cada etapa de refinamiento debe existir un proceso de verificación de la consistencia (la no pérdida de la semántica) o de la emulación de la ejecución.

El problema es la transformación de una especificación ejecutable en código eficiente, tarea que se supone compleja, debido a que:

Se sabe poco acerca de como influyen las optimizaciones realizadas en la especificación sobre la implementación.
El espacio de posibles implementaciones es demasiado extenso.

Especificación operacional

El modelo de especificación operacional [Wegner, 1984] es un nuevo paradigma basado en la programación transformacional. Consiste en definir un sistema mediante un lenguaje de especificación, con su semántica y sintaxis formal, de tal forma que la especificación resultante se pueda ejecutar, como programa, aunque sea de manera poco eficiente. Este modelo es el ideal, es decir, que la especificación sea directamente ejecutable, sin necesidad de ninguna transformación.

Las ventajas de la especificación ejecutable son:

Desarrollo a alto nivel.
Se trabaja directamente solo con la especificación formal, evitando así la discontinuidad del modelo en cascada.
Menor esfuerzo de desarrollo.
Se automatiza el proceso de implementación a partir de la especificación original. También se pueden desarrollar prototipos.
Mayor optimización.
Se pueden experimentar implementaciones alternativas de la especificación formal con el fin de lograr una mayor optimización.
Mayor flexibilidad.
La especificación permite un gran margen de maniobrabilidad y flexibilidad, frente a la programación tradicional, que es más rígida y detallada.
Eliminación de los errores.
Al haber una transformación automática de la especificación formal en la implementación, el sistema está libre de errores. Esto contrasta con la tarea habitual de programación, que es frágil y arriesgada, pues normalmente la lleva a cabo personas diferentes de las que elaboraron la especificación.
Mejor mantenimiento.
El mantenimiento se simplifica notablemente, pues las modificaciones se realizan directamente sobre la especificación, con mayor facilidad, al trabajar directamente con el modelo conceptual. Es a la hora de la implementación cuando estos cambios pueden tener efectos masivos. Por lo tanto, el sistema puede evolucionar más fácilmente, incorporando cada vez más funcionalidades, por lo que su ciclo de vida será más larga.
Mejor documentación.
La información está integrada, en lugar de dispersa y oculta en el código.
Portabilidad.
La especificación formal se realiza sin considerar la implementación, por lo que se puede portar más fácilmente a otra plataforma.
Reusabilidad.
Frente a las librerías de software, que son implimentaciones concretas, se pueden tener librerías de especificaciones.
Ejecución simbólica.
Además de la ejecución directa, existiría la posibilidad de ejecución simbólica. En este caso las entradas son símbolos que representan tipo de valores, en lugar de valores concretos. El comportamiento se determina en función de esos tipos. El objetivo es caracterizar tipos o clases de ejecuciones para reducir el número de pruebas [Kemmerer, 1985].

MENTAL como Lenguaje Formal de Especificación
MENTAL cumple las condiciones para ser un lenguaje formal de especificación:

Se diluye la distinción entre especificación y programación al tratar el “qué” y el “cómo” en un mismo marco conceptual, es decir, la especificación de alto nivel y la especificación de bajo nivel o de detalle. Las mismas primitivas se utilizan a nivel general y a nivel particular, con el grado de detalle que se desee porque siempre están implicados los arquetipos de la conciencia.
Permite integrar las especificaciones operacionales y las descriptivas.
La especificación es abstracta, es decir, no se consideran aspectos implementadores.
A diferencia de los lenguajes de programación de muy alto nivel, no hay brecha semántica entre los conceptos utilizados por el lenguaje y los de especificación.
Al ofrecer un modelo computacional-descriptivo unificado, la automatización de la especificación es más fácil de implementar.
Solo sería necesario un compilador o intérprete para cada plataforma. Dicho compilador o intérprete sería válido para todas las especificaciones. Lo ideal es que todos los sistemas operativos estuvieran basados en MENTAL. Entonces solo sería necesario un intérprete de MENTAL, que sería universal, es decir, válido para todas las plataformas.

Bibliografía

Aho, Alfred V.; Hopcroft, John E.; Ullman, Jeffrey. Estructuras de datos y algoritmos. Addison-Wesley Iberamericana, 1988.
Bishop, Judy. Abstracción de datos. Paraninfo, 1989.
Bulzer, R.; Cheatham, T.E.; Green, C. Software technology in the 1990s: using a new paradigm. IEEE Computer, Nov. 1983, pp. 39-45.
Ince, Darrel C. Z and System Specification. Information and Software Technology, vol. 30, no. 3, Abril 1988, pp 138-145.
Kemmerer, R.A. Testing formal specifications to detect design errors. IEEE Trans. on Software Eng., vol. 11, no. 1, 1985, pp. 32-42.
Mills, Harland D. y Linger, Richard C. Data Structured Programming: Program Design without Arrays and Pointers. IEEE Transactions on Software Engineering, vol. SE-12, no.2, Feb. 1986, pp. 192-197.
Wegner, P. Capital-Intensive Software Technology. IEEE Software, Julio 1984, pp. 7-45, 1984.